An agent reports what it could not get past, and it stays in the run's log (#1500) - #1631

…s log (#1500) (#1631)

* An agent reports what it could not get past, and it stays in the run's log (#1500)

An agent that hits something only the user can fix had one way to say so: prose in
its reply, which the reader has to notice. `update_tickets.md` even spelled the
instruction out per preset ("show an error to the user"), with no mechanism behind it.

It now emits an `error` block, and the framework records it as an event on the run's
own timeline — a headline and the detail below it, red in the log at the point it
happened, counted on the session overview so it survives the log scrolling past.

An error is an event, not a state: nothing clears it, because nothing can un-happen
it. That is what makes it different from the project errors a background job finds
between runs (project-errors.ts) — those are conditions that are true now and clear
themselves when the condition is gone. Two natures, two homes, one red vocabulary.

- every error block in a turn is kept: two things going wrong are two errors
- an error is recorded once however often the agent restates its block, so an agent
  repeating itself does not read as the same failure happening over and over
- update_tickets.md now says which conditions are errors and lets the protocol own how

* Prove the error signal reaches the stream on an agent's real path (#1500)

The parser and the fold were unit-tested, but nothing proved the turn emitter is
actually wired into a run. The backlog-turn signals test now emits an `error` block
alongside the view, session name and ready-for-merge it already covered, and asserts
the event that comes out — verified by unwiring the emitter and watching it fail.

* The error count belongs on the run page, where the log it summarises is (#1500)

Dogfooding found it: the count was only rendered by AgentOverview, which lives on
the PROJECT page. Open a run by its URL — the page that actually carries the log —
and the count was nowhere. The whole point of it is to survive the log scrolling.

It is now its own component, used by both headers: the run's action bar and the
project page's overview.

Placing it also had to be decided rather than guessed. In the action bar it sits with
the controls, not among the branch facts, which give up width as the row fills — the
first attempt put it there and it rendered as "1 erro" against the summary with no
gap. It never shrinks now, and the headline only renders where the row has room for
it (the overview); in the tight bar every headline is the hover instead.

Verified on two real local runs against a seeded project:
- update_tickets on a tickets/ with no lastImportedAt: the agent reached for the
  block unprompted, one red row in the log, "1 error" in the bar
- a two-failure task: two separate rows, "2 errors", both headlines in the hover